This clarifies the security implications as discussed in:

• https://discuss.python.org/t/pep-810-explicit-lazy-imports/104131/41
• and https://discuss.python.org/t/pep-810-explicit-lazy-imports/104131/302

In particular, using pip as an example, as I am one of the maintainers:

1. Pip installs packages into the same environment it runs from.
2. With lazy imports enabled, either globally or via some vendored package explicitly, some pip modules are not reified until later in the run.
3. During installation, pip writes files from a wheel into site-packages.
4. A wheel can include a module name that matches one which will be reified later.
5. When that reification occurs, Python loads the newly installed file instead of pip’s original module, executing its code.

This is problematic because a user does not expect installing a wheel will allow arbitrary code execution. While there are no specific guarantees from pip, the design and philosophy of the wheel format is that it does not have code execution hooks such as pre and post install scripts, and so many would consider this a security issue.

Let me know if you need any more information or changes.

• Change is either:
  • To a Draft PEP
  • To an Accepted or Final PEP, with Steering Council approval
  • To fix an editorial issue (markup, typo, link, header, etc)
• PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

CC: @pablogsal

📚 Documentation preview 📚: https://pep-previews--4660.org.readthedocs.build/